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DEFINITIONS 


CORRECTIVE MAINTENANCE 

Corrective maintenance is any unscheduled maintenance activity required as a 
result of the random failure of equipment It includes the restoration to a 
functional condition of a failed subsystem, end item, component or part 

DEPOT LEVEL MAINTENANCE 

Depot level maintenance consists of those actions that are performed by designated 
maintenance sources (i.e., depots) such as Original Equipment Manufacturers 
(OEMs), NASA Centers, etc. Depot maintenance normally consists of activities 
that require test equipment, facilities, or skills that are not economically available 
at the intermediate level. This may include removal and replacement of individual 
components on an LRU, overhauling, manufacturing of unavailable parts, 
rebuilding parts, and providing technical assistance to the organizational and 
intermediate levels. 

HARDWARE MAINTENANCE ENGINEER 

A Test Control and Monitor System (TCMS) Hardware Maintenance Engineer is a 
member of the TCMS Operations and Maintenance (O&M) organization who is 
responsible for the Organizational Level maintenance of TCMS. He performs 
scheduled and unscheduled Organizational Level maintenance/repair of the TCMS 
hardware. 

INTERMEDIATE LEVEL MAINTENANCE 

Intermediate level maintenance consists of maintenance activities in direct support 
of Organizational maintenance that are at a level between Organizational and 
Depot maintenance. Intermediate level maintenance includes troubleshooting and 
repair of custom LRUs, isolation to the LRU level for TCMS subsystems that arc 
removed during Organizational level maintenance, and monitoring of intermittent 
failures. 

LINE REPLACEABLE UNIT (LRU) 

An LRU is any item that can be removed and replaced during Organizational level 
maintenance in order to keep TCMS operational. LRUs commonly arc printed 
circuit boards, modules, fuses, subassemblies, or in some cases complete 
assemblies such as printers. 

MASTER CONSOLE OPERATIONS ENGINEER 

A TCMS Master Console Operations Engineer (MCOE) is a member of the 
TCMS O&M organization who is responsible for the operation of TCMS. The 
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MCOE manages and controls the overall operation of TCMS via the Master 
Console DP for each test resource set 

MATERIAL SERVICE CENTER (MSC) 

The MSC is an activity established to furnish supply support services to all 
organizations in the immediate area. Each MSC will provide a single point of 
contact with the Kennedy Space Center (KSC) Supply System. It will receive, 
stock, and issue material required by the area served. 

OFF-LINE MAINTENANCE 

Off-line maintenance consists of those functions performed at the Intermediate and 
Depot levels 

OFF-SITE MAINTENANCE 

Off-site maintenance refers to maintenance performed by an organization other 
than Payload Ground Operations Contractor (PGOC). 

ON-LINE MAINTENANCE 

On-line maintenance functions are those performed at the Organizational level. 


ON-SITE MAINTENANCE 

On-site maintenance refers to maintenance performed by PGOC organizations. 

ORGANIZATIONAL LEVEL MAINTENANCE 

Organizational level maintenance consists of actions performed on-line in direct 
support of Operations. It includes scheduled and unscheduled maintenance actions 
required to repair, service, calibrate, and verify systems and subsystems. Repair 
actions will typically be to remove and replace defective LRUs identified by Health 
and Status or diagnostics. 

PIECE PARTS 

Piece parts are the individual components used during Intermediate and Depot 
level, to repair Line Replaceable Units and Shop Replaceable Units. Piece parts 
consist of components such as resistors, capacitors, semiconductors, etc. 

PREVENTIVE MAINTENANCE 

Preventive maintenance consists of those actions performed to retain an item in an 
operable condition by systematic inspection, detection, prevention of incipient 
failures, replacement of life/cycle limited components, adjustment, calibration, 
cleaning, and lubrication. 

SCHEDULED MAINTENANCE 

Scheduled maintenance refers to any preventive maintenance activity. 
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SHOP REPLACEABLE UNIT (SRU) 

SRUs arc components or modules for an LRU that can be removed during 
Intermediate or Depot level maintenance. 

SOFTWARE MAINTENANCE ENGINEER 

A TCMS Software Maintenance Engineer is a member of the TCMS O&M 
organization who is responsible for the troubleshooting and maintenance of TCMS 
software. 

SYSTEM SOFTWARE 

System software refers to Core Electronic Contractor (CEC) provided software. 

UNSCHEDULED MAINTENANCE 

Unscheduled maintenance refers to any corrective mainten an ce activity. 


USER 

A TCMS user is a member of the KSC test engineering, applications, or simulation 
software development organizations. Users are responsible for developing the 
application software and conducting a coordinated test of flight hardware. 
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SECTION I 
INTRODUCTION 


1.1 GENERAL 

This plan describes the maintenance requirements for TCMS and the method for satisfying 
these requirements prior to First Need Date (FND) of the last TCMS set. The method for 
satisfying maintenance requirements following FND of the last TCMS set will be 
addressed by a revision to this plan. This maintenance plan serves as the basic p lannin g 
document for maintenance of this equipment by the NASA Payloads Directorate (CM) 
and the Payload Ground Operations Contractor (PGOC) at KSG 

Throughout this document the terms TCMS Operations and Maintenance (O&M), 
Payloads Logistics, TCMS Sustaining Engineering, Payload Communications, and 
Integrated Network Services refer to the appropriate NASA and PGOC organizations. 

For the duration of their contract, the Core Electronic Contractor (CEC) will provide a 
Set Support Team (SST). One of the primary purposes of this team is to help NASA and 
PGOC operate and mai n ta in TCMS. Throughout this document It is as s u med that SST is 
an integral part of TCMS O&M. 

12 PURPOSE 

The purpose of this plan is to describe the maintenance concept for TCMS hardware and 
system software in order to facilitate activation, transition planning, continuing 
operation. When software maintenance is mentioned in this plan, it refers to main tenance 
of TCMS system software. 

13 APPLICABILITY AND SCOPE 

This plan is applicable to TCMS equipment and the CM and PGOC organizations involved 
with the operation and maintenance of this equipment It describes the maintenance 
approach and p l a nn ed methods for satisfying the TCMS maint^nanre re q uirem ent s. 

1.4 GROUND RULES 

The following ground rules provide the baseline for maintainin g the TCMS equipment; 

a. Preventive and routine maintenance will be integrated with user test and 
hardware utilization schedules and, to the maximum extent possible, 
performed on a non-interference basis. 
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b. On-line (non-intrusive) and/or off-line (intrusive) diagnostic software, and 
self-test hardware capabilities will be able to isolate malfunctions and 
degraded performance to the LRU leveL Corrective organizational level 
maintenance will consist of replacing the LRU with a functional spare. 

c. The Off-Line Support Area (OSA), located in the Space Station Processing 
Facility (SSPF), will provide on-line support in the form of hot spares, 
operations support, and training, as well as vendor on-site support The 
OSA will also provide the capability for intermediate level repair of 
selected TCMS LRUs. Prior to END of the last TCMS set, this capability 
may be utilized on an emergency basis if adequate support is not available 
from other sources. The KSC Core ILMF will provide the capability for 
repair of custom LRUs. 

d. TCMS O&M will provide requirements for Depot Level main^n^nry ( c .g #> 
quality, timelines, spares, etc.) to Payload Logistics in order to select repair 
facilities that meet the needs of TCMS O&M. 

e. Payload Logistics will process LRUs from outside vendors through the 
OSA so TCMS O&M personnel may ensure they are functional before 
returning them to Logistics for stocking as a spare. TCMS LRUs repaired 
by the KSC Core ILMF may be processed directly in to stock. 

£ Automated Test Equipment (ATE) will be utilized when possible for fault 
verification of LRUs. 

Z- Test Program Sets (TPSs) supporting the CEC custom designed hardware, 
and selected Commercial-Off-The-Shelf (COTS) hardware will be contract 
deliverables and will undergo acceptance test and be approved by NASA. 

h. Special Test Tools and Fixtures will be developed as required to 

supplement system level troubleshooting and ATE testing. Configuration 
will be controlled by TCMS O&M utilizing the software tools provided 
with the HP 3070 ATE. 

L TCMS hardware spares will be located in the SSPF. 

j. TCMS O&M will assume operations responsibility at Acceptance Testing 
Complete (ATC) and Organizational Level maintenance responsibility at 
END for each set. The CEC will aim over spares associated with each set 
delivery at set FND. 
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k. In some cases a subsystem may exhibit an intermittent failure. In these * 
cases the Organizational Level Maintenance Engineer may choose to send 
the entire subsystem to the OSA for further troubleshooting and fault 
isolation. 


L When more detailed troubleshooting is required, the Organizational Level 
Maintenance Engineer may replace an entire subassembly. When this 
occurs he will send the suspect assembly to the OSA for fault isolation to 
the defective LRU. 

m. TCMS maintenance responsibilities are shown in table 1-1. The asterisks 
in the table indicate the organization with primary responsibility. For DMS 
kits, the org anizat ions responsible for maintenance have not yet been 
determined. 



CBC 

US 

TCMS 

SUSTAINING 

ENGINEERING 

INTBO RATED 
NETWORK SERVICES 

PAYLOADS 

looigncs 

533 

i j>T ;T iTX 1 9 4 * ,^1 t*! « JBf 

X 








X 





TCMS INTERMEDIATE LEVEL MAINTENANCE PRIOR TO 
FND FOR EACH SET 

X 






TCMS INTERMEDIATE LEVEL MAINTENANCE AFTER WO 
FOR EACH SET 





X 


TCMS DEPOT LEVEL MAINTENANCE PRIOR TO WD FOR 

EACH SET 

X 






TCMS DEPOT LEVEL MAINTENANCE AFTER FND FOR 
EACH SET 





X 


TCMS SOFTWARE MAINTENANCE PUOR TO END Of 
CONTRACT 

X 






TCMS SOFTWARE MAINTENANCE AJTO END OF 

CONTRACT 


X 

X* 






X 







X 







X 


X* 







X 



DMS KJT HARDWARE MAINTENANCE 


X? 




X? 



X? 




X ? 


■■■ 






NOTES: l. * INDICATES ORGANIZATION HAVING PRIMARY RESPONSIBILITY 


1 7 indicates that responsible organizations have not yet been determined 


Table 1-1 

Maintenance Responsibilities Matrix 
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SECTION n 

SYSTEM DESCRIPTION 


.2.1 GENERAL 

TCMS is a major KSC/Core Electronics Contractor (CEC) developed system supporting 
the Space Station Freedom Program (SSFP) at KSC and Johnson Space Center (JSC). 
The equipment consists of Commercial-Off- The-Shelf (COTS) and custom haidwarc, 
software, and firmware. It is configured into various subsystems and sets to meet the 
automation requirements of the space station checkout activities. This section describes 
the major hardware components of TCMS. Figure 2-1 shows a high level view of the 
TCMS architecture. Figure 2-2 shows a typical TCMS operational set configuration 

2.2 TCMS SETS 

TCMS is configured into sets and subsets of end-item equipment at various locations. The 
CEC will deliver three sets (configured as six half sets) for support of the SSPF test stand 
area, one set to the OSA, one set to the hazardous facility, one set to the CAF/CSF at 
JSC, and SNO. TCMS sets are configured from the following assemblies! 

2.2.1 DISPLAY PROCESSOR. The Display Processor (DP) is the system 

interface to the user within the Core distributed architecture. It includes a 32 Bit Central 

Processing Unit (CPU) running UNIX based ULTRIX, a keyboard, a pointing device, a 
primary display, up to three slave monitors, a removable media device, and an MS DOS 
compatible floppy disk drive. The DPs directly interface with the Display Network 
Subsystem (DNS) for accessing the Application Processor (AP), Processed Data Recorder 
(PDR), Data Base Subsystem (DBS), Service Network (SN), Software Production 
Facility (SPF), and external systems such as Payload Data Management System (PDMS). 

2.2.2 APPLICATION PROCESSOR. The Application Processor (AP) is the 
UNIX based data processing node within the Core distributed architecture. It is a 
computation intensive subsystem that primarily executes real time system services and test 
application programs. It consists of two 32 bit CPUs, a 500 megabyte hard disk drive 
(upgradeable to 2 gigabytes), and a removable media device. It interfa ces directly with the 
DNS for access to the DPs and through a Buffer Input/Output Processor (BIOP) to the 
Real Time Network (RTN). 
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FIGURE 2-2 

TYPICAL TCMS OPERATIONAL SET CONFIGURATION 
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2.2.3 FRONT END PROCESSOR. The Front End Processor (FEP) is a universal 
hardware element that performs the data processing necessary to support a wide variety of 
synchronous and asynchronous test article control and data acquisition at the front end 
interfaces. It consists of several CPU and interface modules housed in a Versa Module 
European (VME) bus chassis. The specific interfaces required govern the configuration of 
this subsystem. The FEP has the capability to process all known Space Station, Payi ng 
and Ground Support Equipment (GSE) data types by configuration of interface cards, 
custom software, and customized high performance filter modules. The FEP 
communicates to the other subsystems by way of the RTN through a BIOP. 

2^.4 REAL TIME NETWORK. The Real Time Network (RTN) provides 
message and data communication capability for attached processors. The RTN utilizes star 
topology with hosts connected to the central node through ded icate d , high speed, point- 
to-point links. Through access control of shared data storage area and message routing 
tables, the hosts attached to the RTN can be configured into multiple Test Resource Sets 
(TRSs) to support parallel operations. 

The RTN consists of the Common Data Buffer (CDBFR), host resident BIOPs, and host 
resident Monitor Input/Output Processors (MIOPs). The BIOP supports the exchange of 
single, multiboard, and homogeneous data sets as well as messages. Error detection and 
correction and/or error reporting mechanisms ensure the integrity of the information. The 
MIOP is a unidirectional link that routes data passing through the RTN to a Processed 
Data Recorder (PDR). 


2.2^ DISPLAY NETWORK SUBSYSTEM. The Display Network Subsystem 
(DNS) provides a communication path for system operations. The DNS provides the 
capability to isolate the DPs and APs into Local Display Buses (LDPBs) with filtered 
interfaces to the Global Display Bus (GDPB). The LDPB allows all local traffic to be 
generated without interfering with data traffic on the GDPB. 


2.2.6 SERVICE NET. The Service Net (SN) provides a c nmmiimV-qtjpn path for 
maintenance operations. The SN provides capability for remote and local ac ces s to 
operation and maintenance services for applicable TCMS hardware. 

2*2*7 HARDWARE INTERFACE MODULE. The Hardware Interface Module 
(HIM) acts as the front-end element of TCMS and is connected to the GSE Data Bus for 
communications with the FEP. A FEP may control up to sixteen HIMs via a ground data 
bus. The modular design of the HIM accommodates several types of interfaces depending 
upon the particular configuration req uired 

There are two basic types of HIMs, slave and standalone (also known as a smart or Loc al 
Processor Control (LPC) HIM). The slave HIM is always connected to a FEP and its sole 
function is to transfer measurement data from a GSE device to the FEP, or to pass a 
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command from the FEP to the specific GSE device. Thus, there is no algorithmic 
processing of measurements or command generation in the slave HIM. The standalone 
HIM interfaces to GSE equipment as in a slave HIM, but it gathers measurements and 
issues GSE commands without requiring a FEP. 

2.2.8 PROCESSED DATA RECORDER. The Processed Data Recorder (PDR) 
records data from the RTN to support near real time retrievals and post-test retrievals. 
The data consists predominantly of preprocessed test article data from a FEP. The PDR 
records on two different media simultaneously. One media. Temporary Archive Media 
(TAM), supports the near real time retrievals and the other. Permanent Archive Media 
(PAM), supports a historical record. The PDR interfaces with the RTN for rfata 
recording. 

2.2.9 DATA BASE SUBSYSTEM. The Data Base Subsystem (DBS) provides the 
data management and data handling functions to support the data display and analysis 
performed during and after tests. The DBS supports real time data storage and retrieval 
as well as media library data base management During a test the DBS supports data 
retrieval and analysis of the PDR recorded data. 

2-2.10 DATA MANAGEMENT SYSTEM. A Data Management System (DMS) kit 
is an integrated set of electronic units and an interface device to connect these components 
to a host computer. DMS kits are used for code verification and test support in place of 
the flight hardware. 

The DMS lot typically contains a TCMS Simulation Interface Buffer (SIB) and a set of 
DMS Functional Equivalent Units (FEUs). The SIB is the interface device within the 
DMS kit that provides the interface bridge to the Space Station Freedom environment, 
including the local buses and networks. The FEUs are non-flight versions of various space 
station flight components. 

The DMS kit configuration will vary depending on mission specific requirements and 
phase of testing. The kit operational components are: 

• Simulation Interface Buffer 

• Local Control Workstations (LCWS) 

• System Development and Diagnostic Subunit (SDDS) 

• Network Monitor Subunit (NMS) 

• Network Simulator Subunit (NSS) 

• Functional Equivalent Units 

• Intermediate Rate Gateway (IRGW) 

• Intermediate Gateway (IGW) 

• Multiplexer/Demultiplexer (MDM) 

• Ring Concentrator (RC) 
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• Standard Data Processor (SDP) 

• Mass Storage Unit (MSU) 

• Multipurpose Applications Console (MPAC) 

• Tune Generation Subunit (TGS) 

Hie space station DMS buses and networks include MIL- STD 15S3B local buses, ANSI 
X3T9.5/83- 15FDDI networks, and an EIA RS-422A time distribution bus. 

2.2. 1 1 PATCH PANELS. The TCMS Patch Panels provide for the interconnection 

of TCMS subsystems and the connection with systems external to TCMS. SSPF patching 
is accomplished in die Central Communications Room (Rm. 1025), the Networks Room 
(Rm. 1026), the Communications & Tracking Room (Rm. 1062), the Test & Simulation 
Room (Rm. 2021), the Control Support Room (Rm. 2023), High Bays, Intermediate 
Bays, and Off-line labs (Rms. 1077, 1083 & 1098). Payload Spin Test Facility - 
Replacement (PSTF-R) patching is accomplished in the Flight Data Communications 
Room (Rm. 117). Patching for the Hazardous Operations Support Facility (HOSF) is 
accomplished in the HOSF Control/User Room (Rm. S109). 

Currently there are 97 DMS Kit patch racks, the majority of them being in SSPF 
Rm. 2021. Because of the complexity involved in p atchin g this quantity of racks, default 
patching configurations will be used as much as possible as long as modifications can still 
be made as required. 

Figure 2-3 is a diagram of the patching scheme used on TCMS. This diagram is 
preliminary and has areas of uncertainty shown with question marks. TCMS O&M will 
revise this drawing when the interfaces in question are finned up. For more detailed 
information on TCMS patching, and a description of all the interfaces needed to support 
testing in each of the three facilities (SSPF, PSTF-R, and the HOSF), reference the TCMS 
Communications and Patching Plan (TS-TCMS- 92004). 

2.2. 12 SOFTWARE PRODUCTION FACILITY. The SPF is the hardware set used 

for development and configuration management of applications and simulation software. 

It allows software developers to perform final compiles on the target subsys tems and 
serves as a local repository for downloaded Master Object Data Base (MODB) date, build 
data, and test configuration functions. The SPF is composed of the following baseline 
equipment: 


• Host Computer Systems 

• Ouster Controller to Disk Drive Interface 
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FIGURE 2-4 
SPF ARCHITECTURE 


• Disk Drive Storage Unit 

• Tape Drive 

• Target APs 

• Target PDR 

• Target DBS 

• Line Printers 

Figure 2-4 describes the SPF architecture. For a more detailed description of the SPF 
equipment see Hardware Design and Maintenance for the SPF HWQ (83K03802). 
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2.2. 13 NETWORK INTERFACES. TCMS internal network interfaces include the 
DNS, the SN, and the RTN. The DNS; which consists of the TCMS Global Bus, the 
GDPB, and the LDPB, provides the communication path for normal system operations. 
The SN provides the communication path used for maintenance and diagnostic operations. 
The RTN provides for test data flow between the FEPs and the AP and PDR. In addition, 
it provides subsystem interfaces, message routing, common data storage, and a dat a 
logging interface. Through control of the subsystem interfaces, the RTN provides for the 
addition, deletion, and logical partitioning of attached resources into Test Resource Sets 
(TRSs). 

TCMS external network interfaces are accessed via the Payload Operations Network 
(PON). The PON is an administrative network that provides connectivity to PDMS, 
Payload Office Workstations (POWs), the Production Tracking System (PTS), Computer 
Aided Design/Computer Aided Engineering (CAD/CAE), Broadband Co mmunic ation 
Distribution System (BCDS), and Program Support Communications Network Internet 
(PSCNI). Once approved. Security ESRs that are now pending will protea TCMS and 
Test Articles from access by unauthorized clients. 

Figure 2-5 describes the TCMS network interfaces. For more detailed information on 
TCMS network interfaces, refer to the TCMS Communications and Patching Plan (TS- 
TCMS-92004). 
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FIGURE 2-5 

NETWORK INTERFACES 
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section m 

ORGANIZATIONAL MAINTENANCE 


3.1 GENERAL 

Operations and Maintenance of TCMS sets will initially be the responsibility of the CEC 
The present plan calls for TCMS O&M to assume operations responsibility at Acceptance 
Testing Complete (ATC) and Organizational Level maintenance responsibility at First 
Need Date (FND) for each set Prior to turnover of responsibility, TCMS O&M will 
work with NASA DL and the CEC to operate, monitor health and status, run diagnostics, 
troubleshoot repair, and verily TCMS. This will help to ensure an efficient turn over of 
responsibilities and will give KSC TCMS O&M personnel an insight into the operation 
and maintenance of the TCMS hardware. 

Organizational level maintenance below the LRU level will be minimal with maintenance 
normally consisting of LRU removal and replacement on a scheduled or unsched uled 
basis. TCMS O&M will replace a defective LRU with a spare provided by Lo gistics 
Supply Support or with a hot spare from the Off-Line Support Set (OSS) that is part of 
the OS A. Once the defective LRU is replaced. Operational Readiness Test (ORT) will be 
used to verify the repair, first at the subsystem level and then at the system level. 

Org an izational maintenance consists of preventive (scheduled) and corrective 
(unscheduled) maintenance. TCMS O&M will perform preventive maintmanr^. activities 
primarily during non operating periods in order to optimize system availability for 
operational activities. Corrective maintenance will be performed when problems are 
detected by health and status monitoring or other diagnostic software as described in 
paragraph 5.2. All corrective maintenance activities will be documented per 
SP 10.001-A91, Nonconformance/Problem Reporting And Corrective Action. See 
paragraph 6.3 for more detail. 

3.2 PREVENTIVE MAINTENANCE APPROACH 

TCMS O&M will determine preventive maintenance requirements using applicable system 
specification documents, LS A, and O&M manuals supplied with the hardware. TCMS 
O&M will modify and refine these requirements based on failure and trend d ata ob tained 
from the Production Tracking System (FTS) and other maintenance records. TCMS 
O&M will add or delete specific tasks and adjust maintenance frequencies to minimize 
system down t un e and optimize system performance. TCMS Maintenanc e Engineering 
will provide all preventive maintenance requirements to TCMS Operations En gineeri ng for 
scheduling. 
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TCMS O&M will document these scheduled system maintenance tasks using Preventive 
Maintenance Operations and Maintenance Instructions (PMOMIs). Quality Assurance 
(QA) will approve these procedures prior to their usage. These PMOMIs will specify 
inspection of assemblies for dust, dirt, corrosion, and visible dam ag e or wear. If 
applicable, the PMOMI will specify running diagnostic programs to check the operation of 
systems and subsystems. Each PMOMI will also incorporate the specific maintenance 
tasks required for the identified hardware. 

3.3 CORRECTIVE MAINTENANCE APPROACH 

The TCMS corrective maintenance approach will be to remove and replace the defective 
LRU identified by diagnostics and to perform alignment, and verification of the repaired 
equipment All stages of corrective maintenance will be coordinated with the MCOE. 

Problem Reporting And Corrective Action (PRACA) guidelines and procedures will be 
followed as outlined in section 6 3. After replacing the LRU, the Hardware Maintenance 
En gi n ee r will re-test the subsystem using subsystem Operational Readiness Test (ORT) 
and diagnostics. 


The Hardware Maintenance Engineer may also use general test equipment or specialized 
test equipment such as Configuration, Calibration and Test Set (CCATS), FIT, or RTN 
Analyzer to provide the stimuli and test equipment to validate the set hardware and 
software. 

When the Hardware Maintenance Engineer has repaired the subsystem, he will notify and 
work with the responsible TCMS MCOE who will load the appropriate software, 
configure the set, and run set level ORT and/or diagnostics to functionally test all 
allocated resources. Once the set hardware is satisf actorily repaired, the Hardware 
Maintenance Engineer will summarize the maintenance steps and provide a 
recommendation for closure on the PRACA form. 

3.4 OSA SUPPORT FOR ORGANIZATIONAL MAINTENANCE 

3.4. 1 TIME CRITICAL REPAIR. On some occasions, failure of a TCMS 
component may occur during a critical test or event and the replacement of an entire 
subsystem with a known fully functional subsystem from the Off- Line Support Set may be 
the most efficient and effective method to minimiTe downtime. On these occasions, the 
defective subsystem will be sent to the OSA for troubleshooting and further analysis. 

Once the defective LRU in the subsystem is isolated, it will be removed and replaced with 
a functional spare. 

3.4.2 TROUBLESHOOTING INTERMITTENT FAILURES. On some occasions 
a subsystem will exhibit an intermittent failure that cannot be isolated on-line without 
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causing undue system downtime. When this occurs it will be necessary to remove and 
replace the entire subsystem using a replacement subsystem from the OS A. The suspect 
subsystem will then be sent to the OS A for in-depth troubleshooting. Once the problem is 
isolated and the defective LRU is identified, the subsystem will be repaired by removal and 
replacement of the LRU. The repaired subsystem will then be returned to the Off-Line 
Support Set or the operational set as appropriate. 

3.4.3 HOT SPARES. For reasons such as schedule impact, the Test Conductor in 
conjunction with TCMS O&M may decide that tum-around time for set repair is critical 
In these cases, hot spares may be removed from the Off-Line Support Set Replacement 
LRUs for the Off-Line Support Set will then be ordered through the normal c hanne ls and 
installed when they arrive. Spares from the Off-Line Support Set have several advantages: 

• They are from a working system and therefore have the highest confidence 
level 

• They are located nearby operational sets in the OSA and therefore require 
minimal time to acquire. 

• LRUs requiring configuration may already be in the proper configuration. 

3.5 DMS KTT MAINTENANCE APPROACH 

Maintenance responsibility for DMS kits has not yet been defined. At the present time 
TCMS O&M has no requirements to maintain DMS kits but this is subject to change. 

Since Work Package 2 (WP2) developed DMS kits as Special Test Equipment (STE), 
they will not supply documentation meeting the same standards as GSE. In addition, WP2 
is not currently planning to perform an LSA. They do not intend to provide any Mean 
Time Between Failures (MTBF) data either. Therefore, TCMS O&M does not know the 
extent of the effort required to perform maintenance on the DMS kits. TCMS O&M will 
need to fully understand the effort required and the support provided by WP2 if given the 
responsibility of DMS kit maintenance. Specifics have not been determined at the time of 
this writing. 

3.6 PSTF-R MAINTENANCE APPROACH 

Organizational level maintenance of TCMS equipment located in the Payload Spin Test 
Facility - Replacement (PSTF-R) will be performed in an id entical manner to the 
m a in tenance of TCMS hardware located elsewhere, with few exceptions. Due to the 
l i mit ed amount of equipment and the remote location, maintenance personnel and supplies 
will not be loca t ed in the PSTF-R. Instead, when the TCMS MCOE encounters a 
problem, he will schedule and dispatch personnel from the SSPF to investigate. 

Maintenance personnel will take the replacement LRU and any special tools needed. 
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3.7 TCMS CABLE AND PATCHING MAINTENANCE APPROACH 

TCMS O&M should have sufficient test equipment to determine when an anomaly is due 
to patching or cabling. If a problem exists with a patching cable, TCMS O&M will 
remove and replace it with a suitable spare. When the TCMS Maintenance F.n gin<^ r 
determines that die problem is due to facility cabling, he will notify Payload 
Communications which has the responsibility for resolution of the problem. 

3.8 CAF/CSF MAINTENANCE APPROACH 

At the time of this writing the maintenance approach for the CAF/CSF set located at JSC 
has not been determined. It is envisioned that a snail team from KSC will be permanently 
transferred to Houston to perform Operations and Organizational Maintenance functions. 
Organizational Maintenance approaches will be identical to those used at KSC wherever 
possible. It is also envisioned that a stock of spares will be available at JSC to support 
organizational maintenance and that defective LRUs will be returned to KSC for 
disposition and repair. 

3.9 MAINTENANCE APPROACH FOR SETS LOCATED AT THE CEC 

The CEC will have responsibility for all maintenance of TCMS sets while they are located 
at the CEC This will include responsibility for Organizational level. Intermediate level, 
and Depot level maintenance as well as generation of the required PRACA paperwork. 

The CEC will maintain a dedicated pool of spare LRUs to support maintenance. 

Defective LRUs will be repaired by the CEC, returned to the OEM, or sent to the 
appropriate depot for repair. Repaired LRUs may be verified using SNO, assumin g it is 
not already in use and is in the proper configuration. If spates cannot be verified us ing 
SNO they may be ins tal l ed directly into the system requiring maintenance with no prior 
verification. 

TCMS O&M personnel will be temporarily stationed at the CEC when the TCMS 31 set 
is delivered. This will accomplish the following goals: 

• Familiarize personnel with the system and provide Cn-the-Job Training 
(OJT) 

• Develop and test O&M concepts, procedures, and Operations and 
Maintenance Instructions (OMIs) 

• Assess the adequacy of TCMS system maintenance software, diagnostics, 
and CEC provided test equipment 

• Provide additional O&M support 
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3,10 ‘ MAINTENANCE FLOW DIAGRAMS 

3.10.1 ANOMALY RESOLUTION FLOW. Figure 3-1 describes the overall flow 
for TCMS organizational maintenance and anomaly resolution. In some cases, the root 
cause of a particular problem may not be known and it may therefore be unclear whether 
TCMS O&M or Integrated Network Services has responsibility for correcting the 
problem. In these cases, a joint effort between TCMS O&M and Integrated Network 
Services will be initiated to isolate the problem. TCMS O&M will be the lead during this 
anomaly resolution. Integrated Network Services will be responsible for correcting any 
problems with the POWs. The "Joint TCMS and Integrated Network Services 
Maintenance" box in figure 3-1 refers to this cooperative troubleshooting effort 

Once the problem is isolated to hardware or software, the repair flow continues on 
figure 3-2 or figure 3-4. 

3.10.2 HARDWARE REPAIR FLOW. Figure 3-2 describes the flow for hardware 
maintenance of TCMS. It also includes the decision to use hot spares or to obtain an LRU 
through the normal channels. After completion of the steps on figure 3-2, the flow 
continues on figure 3-1. 

3. 10.3 LRU REPAIR FLOW. Figure 3-3 describes the flow for repair of LRUs 
removed in figure 3-2. The "Vendor Repair" box in this figure refers to both Return to 
Vendor (RTV), and on-site vendor contracts. 

3.10.3.1 Special Hardware Disporitioning The box in figure 3-3 marked "Special 
Hardware Dis positioning" represents the actions taken as the result of recurring fail ure s . 
Each time an LRU is processed through the OSA, failure data will be entered into the 
PTS. When the OSA cannot verify a problem with an LRU sent to the OSA, the PTS will 
be used to determine if the problem is recurring. It is anticipated that the quantity of this 
type of failure will be limited and each will be Handled on a case-by-case hade For 
recurring problems, TCMS O&M personnel have several options depending on the 
circumstances. 

1. If the problem is not an isolated case (Le^ it appears to be a des ign 
problem) and the LRU is custom, TCMS O&M may work with the CEC or 
TCMS Sustaining Engineering to ensure that die problem is properly 
resolved. 

2. If the problem appears to be a design problem with a COTS LRU, TCMS 
O&M may elect to return the LRU, through Payloads T.n gistire , to the 
appropriate repair facility and work with that repair facility to ens ure the 
problem is corrected. 
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3. TCMS O&M may elect to have the LRU scrapped through the Material 
Review Center (MRC). 

Some LRUs will not exhibit a problem after being returned to the OSA. In most of these 
cases this will be because they are functional LRUs that were inadvertently removed 
during Organizational Maintenance. It is conceivable that two or more LRUs may be 
removed and replaced before the defective LRU is isolated. In this case, all removed 
LRUs would be sent to the OSA for identification of the defective LRU and verification of 
the functional LRUs. 

3.10.4 SOFTWARE REPAIR FLOW. Figure 3-4 describes the software 
maintenance flow. This figure contains a box marked "Special Software Dispositioning" 
that represents the actions taken when a software problem cannot be duplicated. 

All software repairs will require PRACA to be opened and coordinated through the 
appropriate approval signatures before work may begin. 

3. 10.4. 1 Special Software Dispositioninp. When software anomalies cannot be readily 
duplicated, TCMS O&M Software Engineering will work with the CEC, TCMS 
Sustaining Engineering, Space Station Payload Software Engineering (SSPSE), or the 
COTS software vendor as appropriate to isolate and resolve the difficulty. TCMS O&M 
Software E ngine ering will track and status these anomalies until they are fully resolved. 

3.11 MAINTENANCE SCENARIOS 

Maintenance scenarios will vary slightly, as described below, depending mi where the 
problem is encountered. Problems may be experienced by users of a DP, users of a POW, 
they may be reported to the MCOE via System Maintenance (SYM), or they may be 
discovered during preventive maintenance or subsystem validation. Regardless of the 
origin of the trouble report, the MCOE will log all anomalies in the problem tracking 
database. The exact details of the database that will be used for problem tracking have not 
been determined at the time of this writing. 

3.11.1 PROBLEM DETECTED AT A DISPLAY PROCESSOR. TTie user's 
method of interfacing with an active set is primarily through a DP in one of the nine user 
control rooms. During testing, the Test Conductor is responsible for directing the te st and 
monitoring all activity in the user room. Users who encounter any hardware or software 
problems will report them directly to the Test Conductor. Hie Test Conductor will then 
notify the Client Support Area via OIS-D. If OIS-D is unavailable, a telephone is 
available. If a Test Conductor is not present, user reports will go directly to the Client 
Support Area. The Client Support Area, which is a subset of the Master Console, serves 
as the link between users and O&M personnel. 
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The MCOE will request QA to open an Interim Problem Report (IPR) before an 
investigation of the problem is started and troubleshooting begins. QA may not be located 
at the set but they will be available via OISD. Refer to section 6.3 for a more detailed 
discussion of IPRs, PRs and PRACA. 

The MCOE will attempt to isolate which subsystem is at fault and whether the problem is 
due to hardware or software. When the MCOE verifies the problem and is unable to 
correct it, TCMS Organizational Maintenance Engineering will be contacted and they will 
begin troubleshooting the problem. Typically, once the problem has been isolated to an 
LRU, the IPR will be upgraded to a Problem Report (PR). TCMS O&M will then remove 
and replace the defective LRU and run subsystem diagnostics to verify the repair. When 
satisfied with the repair, the Maintenance Engineer will notify the MCOE. The MCOE, in 
conjunction with the Maintenance Engineer, will then re-load system software and run 
system level diagnostics to verify the repair. 

When the MCOE and the Maintenance Engineer determine that the system has been 
repaired, it will be returned to operation and the problem report will be closed following 
PRACA guidelines. A Component Problem Report (CPR) will be generated for any 
defective LRUs removed during Organizational Level Maintenance. This CPR, along with 
a copy of the closed system level PR, will accompany the LRU to the repair facility. The 
Client Support Area will then notify the user who originally encountered the problem. 

3-11-2 PROBLEM DETECTED ON A WORKSTATION. If a user on a POW 
encounters a problem, they will notify the Integrated Network Services Help Desk via 
telephone. Integrated Network Services will log the trouble ticket into the Integrated 
Management Tracking System (TMTS) and initiate troubleshooting to de te rmine if it is a 
TCMS problem or an Integrated Network Services problem. If the problem is due to the 
POW or the PON, they will correct the problem. If they determine the problem is due to 
TCMS, they will contact the TCMS Client Support Area and the remainder of the 
scenario will be identical to 3.1 1.1 with the exception that Integrated Network Services 
will be notified when the problem is corrected and they will notify the user who 
encountered the problem. 

3-113 PROBLEM REPORTED TO THE MASTER CONSOLE The MCOE will 
be continually monitoring the TCMS hardware using the Hardware Monitor graphical 
window. This window will provide the MCOE with notification of failures in addition to 
Health and Sta tu s information. In addition. Health and Status will provide a system 
message for any system errors. When an error is reported, the MCOE will then attempt to 
isolate and/or correct the problem. If he is unable to correct the problem, he will notify 
TCMS Orga niz ational Maintenance Engineering and the remainder of the scenario will be 
identical to 3.11.1. 
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3. 1 1.4 PROBLEM DETECTED DURING PREVENTIVE MAINTENANCE If a 
TCMS Maintenance Engineer discovers a problem while performing preventive 
maintenance, he will notify the TCMS Client Support Area via OIS-D or telephone. The 
MCOE may then run additional diagnostics if appropriate. Depending on the severity of 
the problem and the criticality of need for the equipment, the MCOE may opt to delay 
repair until a more appropriate time. The remainder of the scenario will be identical to 
3.11.1. 

3.11.5 PROBLEM DETECTED DURING SUBSYSTEM VALIDATION. If a 
TCMS Maintenance Engineer discovers a problem during subsystem validation, he will 
notify the TCMS Client Support Area via OIS-D or telephone. The MCOE will then 
attempt to isolate and/or correct the problem. If he is unable to correct the problem, he 
will contact TCMS Organizational Maintenance Engineering and the remainder of the 
scenario will be identical to 3.1 1. 1. 

3.12 TEST EQUIPMENT 

The CEC will provide test equipment to support TCMS set maintf> nanr*» in a phased 
m a n ° c r as new TCMS sets are activ at ed. Additional test equipment that may be required 
will be procured later. TCMS O&M will enter this test equipment into the payloads Bar 
Code Equipment Tracking & Utilization System (BETUS) for tracking of location, 
utilization, and calibration due date. The Repeatable Maintenance Recall System (RMRS) 
will notify TCMS O&M in advance of calibration due dates but BETUS will provide 
additional f e a ture s. BETUS utilizes barcodes and will provide real time information that 
will be used for resource planning. Test equipment will be stored in the OSA for on-line 
support of TCMS 
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SECTION IV 

LINE REPLACEABLE UNIT MAINTENANCE 


4.1 GENERAL 

TCMS LRUs removed during Organizational Level Maintenance will be sent to the OSA 
and the associated paperwork will be sent to the MRC for disposition. LRUs will 
normally be forwarded to Logistics for repair at the KSC Core ILMF, the OEM, or at an 
approved repair depot If necessary to keep TCMS sets operational prior to END of the 
last TCMS set O&M may repair LRUs that would normally be repaired elsewhere, 
providing the capability exists. During this developmental period, it is anticipated that 
flexibility will be required to maintain TCMS operational posture. Hus plan will be 
revised to meet maintenance requirements. Figure 3-3 describes the repair flow for LRUs. 

TCMS O&M will use documented PGOC Standard Practices (SPs) to open Problem 
Reports (PRs) - (KSC form 2-151) and troubleshooting plans (KSC form 2-155) for all 
TCMS LRUs . Refer to paragraph 6.3 for PRACA procedures. 

4.2 OFF-LINE SUPPORT AREA 

Hie TCMS Off-Line Support Area (OSA) is scheduled to be located in the SSPF in 
October of 1994 and will include space for locating the CEC deliverable OSA TCMS 
equipment, HP 3070 ATE, test tools, test equipment, and queues for incoming LRUs. It 
will provide space to support current and projected TCMS requirements. TCMS O&M 
will u tiliz e die OSA to satisfy the following requirements: 

a. Providing hot spares for expediting operational support maintenance 

b. On-line operations support 

c. On-line test equipment control and storage 

d. LRU test and verification 

e. Separation of defective LRUs from functional LRUs when multiple LRUs 
are removed during Organizational level troubleshooting 

£ LRU modification and refurbishment 

g. Fabrication and assembly of TCMS special test e q ui pme nt 

h. Hardware Sus tainin g Engineering activity 

i» ATE program development and enhancement 

j. ATE interface control and storage 

k. Documentation library 

L Failure history data from the PTS 

m. TCMS O&M training 

n. Vendor support work areas 

o. Subassembly monitoring 
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p. Staging 

q. TCMS software disk and tape control and storage 


Organizational level failure data will be available to assure duplication of identified 
problems. If TCMS personnel utilizing the OS A cannot duplicate the problem, they will 
subject the LRU to special dispositioning procedures as outlined in paragraph 3.103.1. 

The OSA will have the capability to perform verification testing of all TCMS LRUs using 
the HP3070 ATE or the Off-Line Support Set TCMS O&M will verify all LRU spares 
from outside vendor repair facilities prior to placing them in program stock. LRUs from 
outside vendor sources that fail verification testing will be returned to Payi ng Logistics 
for dispositioning back to the appropriate off-site repair facility for corrective action. The 
OSA will also be used to identify the defective LRU when a group of LRUs is removed 
during Organizational level troubleshooting. The defective LRUs will be repaired and the 
functional LRUs will be verified prior to restocking. 

4-3 INTERMEDIATE AND DEPOT LEVEL MAINTENANCE APPROACH 

TCMS O&M personnel will log LRU’s into the Production Tracking System (PTS) and 
Payloads Logistics will disposition them by utilizing the space nation Source, 
Maintenance, and Recoverability (SMR) codes as guidelines. Appendix A contains a 
listing of the SMR codes. TCMS O&M will assign LRUs to the appropriate OSA test, 
troubleshooting, or repair area or to Logistics for shipment to an outside repair sourc e. 

^•3* 1 REP AIR OF LRUS IN THE OSA. Intermediate Level repair of LRUs will 

not normally be performed in the OSA, however, in emergency situations prior to FND of 
the last TCMS set, TCMS O&M may perform LRU repairs needed to keep TCMS 
operational. By FND of the last TCMS set, it is assumed that all the necess ary repair 
facilities will be in place and qua lifi ed. As needed, TCMS O&M will use Inter mediate snd 
Depot Maintenance Manual Summary Sheets (IDMMSSs) as the procedure to test, repair, 
and verify any LRUs. The IDMMSS will establish uniform acceptance and verification 
criteria for LRUs processed through the OSA. When the OSA completes repair of an 
LRU they will send it to Receiving for processing as a spare. 

4.3.2 REPAIR OF LRUS AT OUTSIDE REPAIR FACILITIES. LRUs will be 
repa ire d at the KSC Core ILMF, OEM sites, and other PGOC Off-Line repair facilities. 
According to the present plan, the KSC Core ILMF will perform Intermediate and Depot 
level repair of custom LRUs. TCMS O&M and Logistics personnel will be re quired to 
communicate with the Core and CCMS II ILMF on a regular basis. This will be 
accomplished via PTS access, status meetings, and tele-conferences. A Memorandum of 
Agreement (MOA) will be formed between the Payload Management and Operations 
Directorate (CM) and the Shuttle Management and Operations Directorate (TM) for 
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utilization of this capability. The OEMs will perform Intermediate and Depot level repair 
of TCMS COTS LRUs at their repair sites. Other PGOC depot capabilities may be 
utilized for select off-line maintenance (cables, structures, etc.). For more detail on Depot 
level repair of LRUs refer to the TCMS Depot Maintenance Support Baseline. 

4.4 TCMS HARDWARE DISPOSITIONING 

TCMS hardware will be dis positioned using documented KSC and PGOC procedures. 
Anticipated dispositions for the various LRU types are described below. 

4.4.1 CUSTOM LRUs. The present plan is for custom LRUs to be sent to the 
KSC Core ILMF for off-line maintenance. This is based on the assumption that the KSC 
Core ILMF organization will be capable of the most economical and timely repair. 

4.4.2 COMMERCIAL-OFF-THE-SHELF LRUs. COTS LRUs will be 
dispositioned to the vendor for maintenance, assuming such service is available and cost 
effective. Items returning from the vendor will require reverification prior to storage as a 
spare. The vendor may return an LRU of a different revision level than the one sent in for 
repair. However, the vendor will be responsible for ensuring compatibility in form, fit, and 
function for LRU's returned. TCMS O&M will identify and track any changes in part 
number or configuration of the LRUs. 

4-4.3 SUBASSEMBLIES. In cases where a complete subassembly has been 
replaced during Orga niz a ti onal maintenance, it will be sent to die OSA for fault isolation 
to the LRU level For example, an entire DP may be replaced in an operational set, and 
the failure will be resolved to the LRU level in the OSA. If, for example, the faulty LRU 
is a disk drive in a DP, it will be replaced and the DP will be verified. After successful 
verification, the DP will either be returned to stock or kept in the OSA as a hot spare. 

The faulty disk drive would then be returned to the OEM for repair. 


4-3 




TS-TCMS-92003 
Rev. Basic 
January 19, 1993 


SECTION V 

DIAGNOSTIC SOFTWARE AND AUTOMATED TEST EQUIPMENT 


5.1 


GENERAL 


The CEC is under contract to deliver automated test equipment, TPSs, and A gnostic 
software to support the Organizational and Intermediate level maintenance of TCMS. 
Software products supporting the various levels of maintenance include, system integrity, 
system maintenance, subsystem maintenance, COTS maintenance diagnostics (including 
Built In Test (BIT)), and automated test software for the HP3070 ATE. 


5.2 


DIAGNOSTICS SOFTWARE 


TCMS is designed to integrate the various levels of maintenance for improved fault 
isolation. The software products supporting Organizational Maintenance inc lude : 


a. 

b. 

c. 

d. 


System integrity - This consists of the on-line non-in trusive tes ting of the 
TRS operational status. 

System main te n a n ce diagnostics - This consists of the off-line intrusive 
ORT and diagnostic testing. 

Subsystem maintenance diagnostics - This consists of the off-line intrusive 
ORT and diagnostic standalone testing. 

COTS m ai n te n a n ce diagnostics - This consists of the diag nostic and 
maintenance software provided by the COTS vendor. 


5.2. 1 SYSTEM INTEGRITY. System integrity detects operational failures 
provides the failure symptoms, and parameters that direct the testing to the next level. 
System integrity provides continuous health and status monitoring of peripherals, 
software, and network interfaces. It also provides fault detection and isolation to a 
subsystem. 

5.2.2 SYSTEM MAINTENANCE DIAGNOSTICS. System maintenance consists 
of off-line intrusive testing of the set's operational status. It is composed of two inte g rated 
functions, system ORT, and system diagnostics. System maintenanc e become s active after 
the set has been configured and subsystems allocated but not operational. System 
maintenance provides a functional checkout of resources and peripherals. S ystem 

maintenance, with system integrity, provides fault detection and isolation to the subsystem 
level. 


5JL3 


SUBSYSTEM MAINTENANCE DIAGNOSTICS. Subsystem maintenance 
consists of the off-line intrusive testing of a subsystem's operational status. It is composed 
of two integrated functions; subsystem ORT and subsystem diagnostics. Subsystem 
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maintenance is active only when a subsystem is not configured or allocated to a TRS. 
Subsystem Maintenance provides fault detection and isolation to an LRU or peripheral 
within the subsystem. 

5.2.4 COTS MAINTENANCE DIAGNOSTICS. For COTS hardware, diagnostics 
rely extensively on BIT or routines supplied by the OEM. Hie Core design approach 
integrates COTS BIT into ORT. ORT provides the executive routines and additional 
testing not provided by BIT. 

5.2.5 DIAGNOSTIC SOFTWARE SUSTAINING ENGINEERING. For the 
duration of the Core contract, CEC's sustaining engineering responsibility includes 
diagnostic software delivered to support TCMS hardware. Problems encountered with 
delivered software will be documented on Problem Reports in accordance with SP 
10.001-A91, Nonconformance/Problem Reporting And Corrective Action System. These 
problem reports will be disposidoned and when appropriate turned over to NASA DL or 
the CEC for resolution. All software will be under control of the Configuration Control 
Board (CCB). A formal release system comparable to the system used for hardware 
modification is anticipated. 

At the end of the Core contract, TCMS Sus tainin g Engineering will assume responsibility 
for all sustaining engineering of TCMS. TCMS O&M Software Engineering will work 
closely with TCMS O&M Hardware Engineering to investigate any suspected ano malies 
with diagnostic software and will document results following PRACA procedures. If 
TCMS O&M Software Engineering determines that the software is at faul t, they will 
contact TCMS Sustaining Engineering. TCMS O&M Software Engineering will then 
work with TCMS Sustaining Engineering to demonstrate the problem, help isolate to the 
software component, and suggest possible solutions. 

If the software component in question is custom, TCMS Sustaining Engineering will 
correct the problem. If the software component in question is COTS, TCMS O&M 
Software Engineering and TCMS Sustaining Engineering will work with the vendor to 
resolve the problem. TCMS Sustaining Engineering will also be responsible for u pdatin g 
all associated documentation as required. The approp riate. Configuration Control Board 
(CCB) will formally control the configuration of all software components. 

53 AUTOMATED TEST EQUIPMENT 

5 3 . 1 GENERAL DESCRIPTION. The goal of the HP3070 ATE is to test, 

identify failing components, and verify LRUs. Upon successful verification, the LRU can 
then be returned to stock as a functional spare. ATE systems allow standardized, efficient, 
high quality testing of PC boards and LRUs. ATE will be utilized whenever feasi ble to 
test and verify TCMS hardware. 
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The HP 3070 has the capability to perform both an in-circuit and a full functional test on 
circuit card LRUs. However, a few of the Core RTN cards u tilize too many sig nals 
simultaneously to perform a full board level functional test on the HP 3070. These boards 
will be fully in-circuit tested and partially functional tested (cluster tests). After repair, 
these cards will then be functionally verified using the Off-Line Support Set or a subset of 
specialized subsystem test fixtures. 

5.3.2 TEST PROGRAM SET ELEMENTS. ATE systems utilize TPSs for each 
Unit Under Test (UUT). A TPS typically consists of software, hardware, and 
documentation as described below: 

a. ATE test program - The test program is a predetermined sequence of 
instructions under computer control to apply stimuli to the LRU under test 
and verify response. The test program controls instruments for the purpose 
of performing functional tests, and in-circuit tests to isolate defective 
elements. 

b. ATE fixture — The fixture is an interface device required to interconnect 
the UUT (Le. LRU) with the ATE system. 

c. Documentation — The following documentation required to support ATE 
testing will be stored in electronic format: 

• Test program software listings 

• Interface device engineering drawings (including wire lists) 

• Test diagrams (identify drivers and sensors) 

• Test program master disks or tapes (archiving) 

• Test program disks 

5-33 TEST PROGRAM CERTIFICATION. TCMS O&M will develop a 
certification process for new or modified Core TPSs. Prior to release of TPSs to the OS A 
or the KSC Core ILMF for operational use, TCMS will certify the program according to 
this procedure. This certification ensures that requirements are xatisfiftri, standards of 
quality are maintained and the correct documentation is produced for each TPS. 

5-3.4 NEW TPS DEVELOPMENT. Additional TPSs will be needed in time as 
new LRUs are added to the system or existing LRUs are modified. TCMS O&M will 
have the responsibility of developing any new TPSs required. 

533 MAI. fENANCE PLAN FOR THE HP3070 ATE. It is envisioned that 
maintenance for the HP3070 ATE will be ha n dl e d in a similar manner to other existing 
HP3070s at KSC. At the present time this is done by way of a vendor support contract 
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5.4 CONFIGURATION, CALIBRATION, AND TEST SET 

5.4.1 GENERAL DESCRIPTION. CCATS provides the ability to measure the 
time required for a command or measurement to be processed through a subsystem within 
the test connection from a DP to a FEP. CCATS can concurrently monitor the front end 
and back end of a subsystem in the test connection. CCATS interfaces to the FEP via the 
maintenance port and controls the diagnostic activities of the FEP. In particular, CCATS 
coordinates the interfaces and performs the appropriate instrument setups. By 
commanding the FEP via the diagnostics, the CCATS controller can request a test for a 
particular interface. Then CCATS either provides the stimulus or measures the interface 
as appropriate for the test CCATS then compares the results and displays a message on 
the controlling DP or the CCATS terminal. 

CCATS provides for either remote control of CCATS equipment from a DP or local 
control from a CCATS terminal in a CCATS standalone mode. CCATS can display 
captured data at a DP in the Core test configuration or locally at a CCATS terminal in a 
CCATS standalone mode. 

5.4.2 CCATS SOFTWARE MAINTENANCE. Most of the software used in 
CCATS is COTS. It consists primarily of device drivers for the various instruments and 
associated software for the FDDI, IEEE 488, LAN and WAN analyzers. The CEC is 
writing a few custom device drivers. The maintenance approach for this software will be 
identical to the approach for other TCMS software (COTS and custom). CCATS 
software maintenance flow will follow the appropriate steps shown in figure 3-4. 

5.4.3 CCATS HARDWARE MAINTENANCE. Hie CCATS consists of a FEP 
s i m u l at o r, COTS test instruments, and COTS network analyzers. The FEP simulator is 
m ade up of standard TCMS FEP LRUs and will be maintained exactly lita*. any other 
TCMS FEP hardware. The only other custom LRU in the CCATS is a Single Board 
Computer (SBC) which is custom only because of the Programmable Read Only Memory 
(PROM) ins ta lled . For maintenance of the SBC, the PROMs will be removed and the imit 
will be returned to the vendor. The remainder of the CCATS is composed of COTS 
LRUs that will also be returned to the vendor for maintenance. 

5.5 REAL TIME NETWORK ANALYZER. 

5~5.1 GENERAL DESCRIPTION. The RTN analyzer, which is a tool for 
monitoring the activity through the RTN, will be physically located in SNO. It co nsis ts 
mostly of Core custom LRUs such as Input/Output Processors (IOPs) which are identical 
to those used in the RTN. There is currently only one custom card, the link tester, which 
is unique to the RTN analyzer. 
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5.5.2 RTN ANALYZER SOFTWARE MAINTENANCE. Almost aU of the 
software used in the RTN Analyzer is HSSC Custom software. This software will analyze 
the RTN to assist in troubleshooting problems with the hardware. The maintenance 
approach for this software will be identical to the approach for other TCMS software 
(custom). The RTN Analyzer software maintenance flow will follow the appropriate steps 
shown in figure 3-4. 

5.5.3 RTN ANALYZER HARDWARE MAINTENANCE. Fault isolation of 
anomalies in the RTN Analyzer will be accomplished using the internal software 
diagnostics and routines that are provided with the unit Cnee the anomaly has been 
traced to the defective LRU, it will be removed and replaced with a functional spare. 

Repair of defective LRUs will be handled similarly to other TCMS LRUs. It is anticipated 
that common custom LRUs will be repaired by the KSC Core ILMF. This in cl u des the 
Link Tester LRU that is unique to the RTN analyzer. The CEC does not plan to provide a 
TPS for this LRU so CCMS will need to generate a TPS if they plan to use the HP3070. 
Another alternative would be to install the LRU in a VME chassis and troubleshoot using 
external test equipment along with the diagnostic software provided with the FIT. 

5.6 FUNCTIONAL INTERFACE TOOL. 

5.6.1 GENERAL DESCRIPTION. The Functional Interface Tool (FIT) is a 
portable device that is designed to perform card level testing of the custom Input/Output 
(I/O) cards in the HIM and the I/O FEP. Specifically, the FIT is able to simulate, record, 
and verify the KIM'S responses to roll calls, FEP commands/queries and I/O card 
tra nsa ctions. The FIT consists of an SBC, keyboard, monitor, and a floppy drive. The 
FIT consists of mostly COTS LRUs with some custom LRUs that are id entical to those 
used in the FEP, and one custom LRU that is unique to the FIT. The FIT is self contained 
and designed to be hand carried. 

5-6.2 FIT SOFTWARE MAINTENANCE. FIT Software is currently over 300K 
bytes of code, stack, and da t a, not including Vx Works. Close to half of this consists of 
ta bl es and processing software for the various forms and m en us. Other large dpta 
structures include the FEP Simulator Task Table (16K) and Transaction Table (32K). The 
final product is envisioned to exceed 400K bytes. Almost one third of this code supports 
hardware maintenance functions including debug forms and Built In Test (Bin* The 
m a in tenance approach for this software will be identical to the approach for other TCMS 
software (COTS and custom). FIT software mainte nan ce flow will follow the appropriate 
steps shown in figure 3-4. 

5.63 FIT HARDWARE MAINTENANCE. Fault isolation of anomalies on the 
FIT will be accomplished using the internal software diagnostics and routines that are 
provided with the u nit . There arc three levels of diagnostics available. First, there is a 
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menu driven self test provided by the CEC that will check out most of the FIT 
functionality. If the problem requires more in-depth troubleshooting there is a second 
level of manual diagnostic software also provided by the CEC This level allows 
manipulation of data on individual registers. The third level of diagnostic software 
consists of the routines provided with the COTS Single Board Computer. 

Using these diagnostic software routines, the TCMS Maintenance Engineer will 
troubleshoot any FIT anomalies to the LRU level. The LRU will then be removed and 
replaced with a spare. 

Repair of the LRU will depend on its type. COTS LRUs will normally be sent to the 
vendor for repair. The custom LRUs that are the same as used in the FEP will be repaired 
in die same manner as any other custom TCMS LRU. 

The FIT unique custom card (Nomenclature TBD) is a special case. Since this LRU falls 
under the category of a Core common custom LRU, it will be repaired at the KSC Core 
ILMF. However, the CEC is currently not required to provide a TPS for this LRU. A 
IPS will need to be developed if the KSC Core ILMF plans to use the HP3070. Another 
alternative would be to troubleshoot using external test equipment along with the 
diagnostic software provided with the FIT. 
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SECTION VI 

HARDWARE TRACKING SYSTEMS 


6. 1 KENNEDY INVENTORY MANAGEMENT SYSTEM 

Payload Logistics will use the Kennedy Inventory Management System (KIMS) to track 
all TCMS hardware, repair piece parts, and consumables while they are in stock. When 
TCMS hardware is removed from stock it will be tracked by other systems as described 
below. KIMS will also track all TCMS hardware through the repair cycle, including 
re tum-to- vendor repairs. 

6.2 HARDWARE CONFIGURATION MANAGEMENT DATABASE 

Hie hardware configuration management database will contain all information necessary 
to determine the exact configuration of the TCMS sets and the location of individual 
LRUs at any point in time. This will include the nomenclature, part number, serial 
number, revision level, bar code number, and movement history of all hardware installed in 
each TCMS set. 

Information about LRU movement and revision level updates needs to be maintain^ on a 
real time basis. The system to track this information has not yet been selected but should 
be in place prior to the activation of TCMS operations. One possibility that is being 
investigated is the expansion of PTS to support this function. New equipment will be 
added to this data base as it enters inventory. Various reports and retrieval data will also 
be available. 

63 PROBLEM REPORTING AND CORRECTIVE ACTION 

The MCOE will be TCMS O&Ms point-of-contact for all anomalies within the TCMS 
set He will receive anomaly reports via the Test Conductor, the Client Support Area, 
and/or system software messages and will initiate IPRs. TCMS O&M personnel will 
follow the guidelines of PGOC Standard Practice SP 10.001-A91, 
Nonconfor man c e /Problem Reporting And Corrective Action System for all activities 
involving Problem Reporting And Corrective Action (PRACA). 

63.1 PRACA SCENARIO. When an anomaly is reported, the MCOE will initiate 
an IPR to document the investigation and will enter the appropriate data into the TCMS 
problem tracking da t a b ase. The exact details of this dataha^ have not been determined at 
the time of this writing. The MCOE will also notify the QA inspector/monitor who will 
assign a number to the IPR and enter the appropriate data into PRACA. PDMS will be 
used for recording PRs and IPRs. 
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The MCOE will then run appropriate diagnostics to attempt to isolate the problem. If the 
MCOE determines the anomaly is due to a procedural error or other explained condition, 
a statement will be made on the problem report that the equipment was not damaged. 
TCMS O&M, their NASA counterpart, and the QA inspector will sign the PRACA form. 
The QA inspector will then enter the data into PRACA and the IPR will be closed. 

If die anomaly requires maintenance action, the MCOE will notify the TCMS Hardware or 
Software Maintenance Engineer who will continue the troubleshooting. As work 
continues, the Maintenance Engineer will record all troubleshooting steps taken on the 
PRACA paperwork. When troubleshooting actions require that integrity seals be broken, 
QA will become actively involved. The QA inspector will witness and stamp the steps on 
the PRACA paperwork for all physical intrusion. QA will also document this intrusion in, 
and maintain the Break Of Integrity (BOI) log. When the Maintenance Engineer isolates 
the anomaly to a specific item of hardware or software, he will upgrade the IPR to a PR. 

Once the defective LRU has been isolated, it will be removed and replaced with a hot 
spare from the OS A or a spare from Logistics. Either way, the defective LRU will be 
turned in to Logistics and they will issue a replacement LRU providing they have one 
available. If a replacement LRU is not available. Logistics will issue a credit and provide a 
replacement as soon a one becomes available, either through repair or procurement If the 
LRU is a non-repairable item, it will be ordered via KIMS which will initiate an order for a 
replacement LRU from the vendor when the inventory reaches die minimum level. 

After die repair has been satisfactorily completed the Maintenance En gin«»r will run 
appropriate subsystem diagnostics to verify that the equipment has b ee n returned to an 
operable condition. Once satisfied with the repair, the Maintenance En gineer will notify 
the MCOE who will load and configure the equipment The MCOE will then run the 
appropriate diagnostics to verify proper system operation. Once TCMS O&M is satisfied 
with the repair, the Maintenance Engineer will complete the PRACA paperwork including 
a summary of troubleshooting and a recommendation for closure. With concurrence of 
QE, the Maintenance Engineer, his NASA counterpart, and the QA inspector will sign the 
PRACA form. QA will then enter the appropriate data into PRACA and officially close 
the Problem Report. 

A CPR will be generated for any defective LRUs removed during Organizational Level 
M ai n te n a n ce. This LRU level CPR, along with a copy of the closed system level PR, will 
accompany the LRU to the repair facility. 

6.4 PRODUCTION TRACKING SYSTEM 

The Production Tracking System (PTS) is a data base management system in a Local Area 
Network (LAN) configuration used for tracking accountability of Work Authorization 
Documents (W ADs) and associated LRUs in the repair cycle. TCMS O&M will be 
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responsible for operation, system administration, and maintenance of PTS hardware and 
software. OEM service contracts and/or on-site support will be used as necessary to 
maintain PTS. 

PTS will track LRUs in the OS A and at outside vendor sites. PTS u tilizes bar code 
technology to facilitate LRU and WAD tracking in real time. In addition, the PTS 
m ai n ta ins and archives data applicable to LRU failure, repair, and configuration. This data 
is available real time and will be utilized for various maintenance management functions. 
Since 1986, CCMS O&M has had a Production Tracking System in place that is totally 
compatible with the Payloads PTS. The current plan is for the CCMS n ILMF to perform 
Intermediate Level Maintenance on both TCMS and CCMS custom LRUs. Therefore, the 
Payloads PTS is required to have the capability to access the Shuttle PTS Hatah^ 


6 J BAR CODE EQUIPMENT TRACKING & UTILIZATION SYSTEM 

BETUS is a data base management system used for the tracking and accountability of test 
equipment and selected bench stock items for TCMS. BETUS utilizes bar code 
technology to facilitate data entry and updating. Bench stock will be ordered via KIMS 
and when received it will be entered into BETUS for tracking in ternal to the OS A. TCMS 
O&M will be responsible for operation, system administration, and maintenance of 
BETUS hardware and software. 
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SECTION vn 
DOCUMENTATION 


7.1 ORGANIZATIONAL LEVEL 

TCMS O&M will document all unscheduled system maintenance tasks in PRACA 
following the guidelines of PGOC Standard Practice SP 10.001-A91, 
Nonconformance/Problem Reporting And Corrective Action System. For more 
information on PRACA see paragraph 63. 

TCMS O&M will use Preventive Maintenance Operational and Maintenance Instruction 
(PMOMIs) to perform scheduled system maintenance tasks. Results will be documented 
on PMOMI summary sheets. The PMOMIs will specify inspection of assemblies for dust, 
dirt, corrosion, and visible damage or wear. PMOMIs will direct the inspection of cabling 
and connectors for wear or damage such as cuts, breaks, or fraying but connectors will not 
normally be de-mated for inspection since progressive deterioration may occur. If 
applicable, the PMOMI will specify running diagnostic programs to check the operation of 
systems and subsystems. Each PMOMI will incorporate these general requi remen ts and 
specific maintenance tasks required for the identified hardware. 

Completed PRACA forms and PMOMI summary sheets will be sent to the Technica l Data 
Center (TDC) for storage and archiving. 

7J2 INTERMEDIATE LEVEL 

A complete set of Intermediate and Depot Maintenance Manuals (IDMMs) for TCMS 
hardware will be loca t e d in the OS A to support Organizational Level maintenance and 
emergency Intermediate Level maintenance of LRUs as outlined in paragraph 43.1. The 
master set of IDMMs will reside on PDMS H, Technical Documentation Subsystem. The 
CEC will initially provide IDMMs for all repairable TCMS LRUs and SRUs. These 
IDMMs will be either vendor provided manuals for COTS hardware or CEC developed 
m a nual s for custom hardware. IDMMs provide procedures for inspection, cleaning, 
lubrication, prevention of incipient failures, replacement of life/cycie limite d components, 
adjustment, and verification. IDMMs also contain technical reference data required to 
perform Intermediate Level Maintenance. OSA engineering personnel will document 
LRU and SRU repairs using Intermediate and Depot Maintenance Manual Summary 
Sheets (IDMMSSs). Completed IDMMSSs will be sent to the TDC for storage. 

73 DOCUMENTATION DEVELOPMENT 

TCMS O&M will ge ner a t e OMIs and PMOMIs in accordance with the Payload 
Operations WAD Handbook, KCA-HB-0018.0 and PGOC Standard Practice 
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SP 8.007-A91. Vendor supplied manuals will be used as much as possible to mini mi 
redundancy and cost Any future revisions to documentation developed by TCMS O&M 
will be the responsibility of TCMS O&M. 

TCMS Sustaining Engineering will be responsible for any revisions to TCMS system 
software or hardware. As part of this responsibility they will also update any drawings or 
other documentation as required. 

Payload Logistics will develop new IDMMs as required for new or modified LRUs. 

7.4 HARDWARE CONFIGURATION MANAGEMENT 

The configuration management system will be used for tracking the current configuration 
of, providing for the assured integrity of, and introducing approved changes to, the TCMS 
hardware, not including test equipment 

The configuration management system identifies the hardware items to be placed under 
configuration control and describes their baseline configuration. The Payload Level TTT/TV 
CCB addresses proposed changes to the configuration baseline. Verification of changes is 
accomplished by reviews to assure that hardware design satisfi es approved requirements 
and that modifications have been incorporated per the modification instructions. 
Configuration accounting is accomplished by an automated configuration management 
tracking system that provides visibility of all changes to the current baseline. 

7.4.1 CONFIGURATION IDENTIFICATION FOR TCMS HARDWARE. 
Configuration identification is the process of selecting hardware items to be under 
configuration control, describing their baseline configuration in terms of 
documentation and hardware identifiers, and the system for preparing, maintaining, and 
releasing configuration documentation. The functions of configuration i de ntification are 
described in the following paragraphs. 

7.4.1.1 Identification of TCMS Hardware Under Configuration Control . TCMS 
hardware items to be under configuration control are established by NASA and accepted 
by the PGOC during transition. The PGOC authorization to add or delete TCMS 
hardware items to/from the accepted baseline is by Configuration Control Board Directive 
(CCBD) and/or Contract Change Order (CO). PGOC Configuration Management 
Department will maintain a current listing of items under formal program/project 
configuration control. 

7.4. 1^2 . Baseline Identification for TC MS Ground Hardware . The configuration 
baseline is the current defined and approved configuration used as a re fe renc e point for 
program/project planning purposes and as a point of departure for control of changes. 
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The baseline identification and all approved changes thereto are maintained by the PGOC 
Configuration Management Organization. 

7.4.1.3 Engineering Documentation Preparation. Maintenance. Records, and Release 
System . The PGOC will use or adapt existing methods and systems for the preparation, 
maintenance, record keeping and release of engineering documentation. Existing systems 
will be used except when system changes will require NASA approval prior to 
implementation, e.g., if changes affect non-PGOC. 

7.5 SOFTWARE CONFIGURATION MANAGEMENT 

Stringent control of TCMS System Software, Test Application Software, Simulation 
Software, MODB Utilities, Test End Item Data Bank, Flight Software, DMS Kit 
Software, and Ground Support Equipment System Software is necessary for the 
successful operation of TCMS. The plan for formal configuration control is d es cribed in 
th e Spa ce Station Test, Control and Monitor System (TCMS) Production Control Plan, 
K-CTE-63.2. Refer to this document for more detail. 
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section vm 

OFF-SITE MAINTENANCE AND VENDOR REPAIR 


8.1 GENERAL 

Off- Site Maintenance will be the preferred method of repair and modification for TCMS 
COTS LRUs and subassemblies. This includes maintenance, complicated adjustments, 
modifications, and refurbishment of items removed during intermediate or organizational 
level maintenance. The off-site maintenance facility will normally be the Original 
Equipment Manufacturer (OEM). 

When off-site maintenance is needed. Payloads Logistics will utilize OEM and commercial 
maintenance sources to provide repair services for TCMS equipment 

8.2 LRU REPAIR OR EXCHANGE 

When a repairable LRU has been dis positioned off-site, the appropriate vendor or the 
XSC Core ILMF will repair, exchange or scrap the LRU in accordance with established 
and approved criteria. LRUs received from the vendor must be compatible in form, fit 
and function to those sent 

Quality Engineering will monitor off-site work performed by vendors. Contractor Source 
Inspection and Government Source Inspection will be performed as required TCMS 
O&M will monitor work performed at the XSC Core ILMF. 

Payload Logistics will track LRUs sent to a vendor using the Rcturn-to- Vendor (RTV) 
portion of the KIMS. In addition, the TCMS O&M PTS will be able to communicate with 
the CCMS PTS for statusing of TCMS LRUs being repaired at the XSC Core ILMF. 

8-3 ORIGINAL EQUIPMENT MANUFACTURER MAINTENANCE 
CONTRACTS 

Where limited maintenance capability exists for specific types of TCMS equipment. 
Original Equipment Manufacturer (OEM) full service mflintrnann* contracts will be 
utilized. Guaranteed response time versus cost of the coverage will be analyzed. The 
most economical solution that will meet TCMS O&M technical and srhiyfyif requirements 
will be selected and administered by Payload Logistics. Work areas will be provided in the 
OSA to support maintenance contract vendors. 

Quality will review all OEM contracts for Quality Statement Of Work (SOW) 
development and approval of required Quality provisions for the Maintenance Contractor. 
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SECTION IX 
LOGISTICS SUPPORT 


9.1 GENERAL 

The TCMS Integrated Logistics Support Plan will document logistics support to TCMS. 
All TCMS logistics planning will be in accordance with the space station Program 
Definitions and Requirements Document (PDRD) Section 4 Part 2, the KSC space station 
Integrated Logistics Support Requirements (KSC-STA-20), and its subsequent 
attachments. TCMS logistics support will stress the aspects of cost, commonality, and 
utilization of existing logistics resources at all times. TCMS Production Support will 
actively interface with operations and maintenance personnel, hardware sustaining 
engineering, sub-contracts, vendors, and quality engineering to meet the TCMS logistics 
support requirements. TCMS Production Support will provide Logistics Support 
Analysis, Technical Data and Documentation (TD&D), Maintenance Support Equipment 
(MSE), Supply Support, Packaging Handlii^g, Storage and Transportation (PHS&T), 
training, logistics facilities, and procurement capabilities and support to TCMS. 

9.2 LOGISTICS SUPPORT 


All TCMS logistics planning and support will be in accordance with the Space Station 
Program Definitions and Requirements Document (PDRD), section 4, part 2 and the KSC 
Space Station Integrated Logistics Support Requirements (KSC-STA-20) and its 
subsequent attachments. These are listed below for reference. 


KSC-STA-20. 01 
KSC-STA-20. 02 
KSC-STA-20.03 
KSC-STA-20.04 
KSC-STA-20.05 

KSC-STA-20.06 

* KSC-STA-20.07 
KSC-STA-20.08 
KSC-STA-20.09 
KSC-STA-20. 10 

* Note: This reference document is 


Logistics Support Analysis Plan 
Technical Data and Documentation Plan 
Maintenance Support Equipment Plan 
Supply Support Plan 
Packaging, Handling, Storage, and 
Transportation Plan 
Logistics Information System Plan 
Maintenance Plan 
LMRT Plan 

Personnel and Training Plan 

Logistics Facilities Plan 

Space Station Maintenance Plan. TCMS 


will be maintained in accordance with TS-TCMS-92003. 
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9.3 LOGISTICS SUPPORT ANALYSIS 

The CEC will perform LSA for the TCMS hardware. The LSA will be the principle tool 
utilized to identify the TCMS logistics support requirements. The CEC will conduct 
equipment level analysis on candidate TCMS hardware. This analysis will consist of 
performing Repair Level Analysis (RLA) to determine economical repair levels 
(intermediate, depot, discard) of LRUs and SRUs. A detailed analysis will then be 
conducted to identify logistics resources required to accomplish the appropriate level of 
repair. Necessary level of spare LRUs, SRUs, piece parts, and consumables will be 
identified with appropriate minimum and maximum levels. All TCMS LSA data 
developed by CEC will be provided to TCMS Logistics for review to insure support 
requirement identification is coordinated for continued support of the system. The CEC 
will develop TCMS LSA data in accordance with the KSC Space Station LSA Plan (KSC- 
STA-20.01). Core will provided LSA data to CM logistics organizations on a scheduled 
basis. Final transfer of TCMS LSA from the CEC to TCMS Logistics will take place at 
the end of the Core contract Continued update and development of TCMS LSA data will 
be the responsibility of TCMS Production Support an4 will be based on actual TCMS 
operations and maintenance experience. 

9.4 TECHNICAL DATA AND DOCUMENTATION 

TCMS logistics TD&D planning will be developed in accordance with KSC Space Station 
TD&D Plan (KSC-STA-20.02). Logistics support TD&D will be developed to meet 
TCMS logistics support and off-line maintenance requirements. The CEC will develop the 
initial TD&D for TCMS. Scheduled reviews of the CEC TCMS TD&D will take place to 
ensure that system logistics documentation requirements are easily transferred to TCMS 
Logistics. Phased TD&D responsibility transfers will occur throughout the Core contract 
Transferred TCMS logistics TD&D will become the responsibility of TCMS Production 
Support for redevelopment or modification for the life of the system as required. 

9.5 MAINTENANCE SUPPORT EQUIPMENT 

TCMS Maintenance Support Equipment (MSE) planning will be developed in accordance 
with the KSC Space Station MSE Plan (KSC-STA- 20.03). The CEC will identify and 
procure MSE items necessary to support TCMS. Any shortfalls in MSE procurement 
will be coordinated with CM logistics organizations to avoid continued maintenance 
shortfalls. Scheduled reviews of MSE procurement and support requirements will take 
place to ensure proper integration into PGOC operations. TCMS Production Support and 
the TCMS Operations and Maintenance organizations will provide continued support of 
TCMS MSE. All MSE will be maintained in a test pool controlled by BETUS. 
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9.6 SUPPLY SUPPORT 

TCMS Supply Support planning will be developed in accordance with the KSC Space 
Station Supply Support Plan (KSC-STA-20.04). The CEC will identify and provide initial 
spares for TCMS Hardware. Ideally, initial spares will be of a quantity sufficient to allow 
TCMS Logistics time to provide for continuing spares acquisition. Schedule reviews of 
CEC spares procurement requirements will take place as a part of the provisioning 
conferences to ensure proper integration into PGOC operations. TCMS Production 
Support org aniza tions will store all TCMS LRUs and SRUs in a functional condition to 
satisfy requests submitted by TCMS O&M utilizing the standard Parts and Material 
Request (PMR). 

9.6.1 MATERIAL SERVICE CENTER. The MSC is responsible for processing 
LRUs in support of TCMS operations, maintaining bench stock parts, and processing 
documentation. In addition TCMS property movement, transfers, equipment excess, and 
RTV items will be coordinated with the MSC. The MSC will be located in the SSPF for 
support to organizational and off-line maintenance. 

9.6.2 PIECE PARTS AND BENCH STOCK. Piece parts required to meet 
operational needs and schedules will be identified by Production Support for provisioning. 
Maximum and minimum levels will be established and their usage will be monitored. 

9.6.3 OPERATING SUPPLIES. Operating supplies are those materials necessary 
to support the SSPF administratively. TCMS O&M will identify and submit to the 
appropriate provisioning organization, operating material used on a recurring basis in 
support of TCMS. When required to meet operational needs, these items will be entered 
into the appropriate bench stock maintained by Production Support. Hand tools will be 
issued to each TCMS technician for u tiliza tion on the TCMS equipment Each technician 
will check out any special tools required using hand receipts. 

9.6.4 PROPERTY ADMINISTRATION, All NASA capital equipment will be 
tracked in the NASA Equipment Management System (NEMS). Production Support 
property administration organizations will be the focal point for assuring a smooth transfer 
of accountability for TCMS equipment entering the inventory and TCMS equipment being 
removed from service. 

9.7 PACKAGING, HANDLING, STORAGE, AND TRANSPORTATION 

TCMS PHS&T planning will be developed in accordance with the KSC Space Station 
PHS&T Plan (KSC-STA-20.05). The CEC will develop initial PHS&T requirements. 
Scheduled reviews of CEC developed PHS&T requirements will take place to ensure 
proper integration into PGOC operations. The CEC has the responsibility for initial 
shipment of TCMS hardware, software, initial spares, support equipment and all other 
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CEC TCMS procured items to the designated KSC location. Continuing PHS&T support 
will be the responsibly of TCMS Production Support 

9.8 TRAINING 

TCMS training will be developed in accordance with the KSC Space Station Training Plan 
(KSC-STA-20.09). The CEC will develop initial training courses. Scheduled reviews of 
CEC developed training courses will take place to ensure proper integration into PGOC 
operations. The CEC has the responsibility to train TCMS personnel in operations, 
utilization, maintenance, and support of TCMS hardware, software, and support 
equipment This training will be to the appropriate level for personnel and will impart 
knowledge, skills, and abilities they will require to perform their duties. Developed 
courses will include complete documentation and provide an in-class instructor. The 
developed courses will include instruction packages that run on workstations and will be 
available on easily reproducible media. The CEC will transfer all CEC training material 
(slides, overheads, video, mock-ups, simulators, and documentation) to the appropriate 
PGOC organizations for continued TCMS training. Due to the system’s complex^ and 
the size of the TCMS student population, it is anticipated that the OSA and Space Station 
Software Engineering will provide TCMS hardware, software, support equipment and 
appropriate personnel to support continued TCMS training as required. TCMS O&M will 
coordinate with Production Support Technical Training for the development and 
maintenance of continued TCMS training. Production Support Technical Training will 
schedule and track TCMS training in the Training Tracking and Scheduling System 
(TTSS) database. Technical Training will coordinate TCMS training closely with TCMS 
O&M to avoid impacts with OSA operations and to ensure the availability of the 
necessary equipment and personnel. 

9.9 LOGISTICS FACILITIES 

TCMS logistics facilities will be developed in accordance with the KSC Space Station 
Logistics Facilities Plan (KSC-STA-20.10). The CEC will develop TCMS logistics 
facility requirements. Scheduled reviews of CEC developed logistics facility requirements 
will take place to ensure proper integration into PGOC operations. Utilization of existing 
KSC logistics facilities will be exercised at all times to avoid unnecessary facility cost 
impacts. 

9.10 OSA SUPPORT 

Production Support will perform logistics research on piece-part and SRU hardware 
needed to support the LRU repair cycle as required. Information necessary to initiate 
procurement documents for Non-Stock Listed (NSL) items will be researched and 
provided. 
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